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DESCRIPTION 

HOME GATEWAY 

BACKGROUND OF THE INVENTION 
5 Cross Reference to Related Applications 

This application is related to U.S. application Ser. No. 09/140,899, filed August 25, 
1998, entitled "BITMAP TRANSFER IN PLUG AND PLAY NETWORK", U.S. 
application Ser. No. 09/144,678, filed August 31, 1999, entitled "HOME DIGITAL 
NETWORK INTERFACE", and U.S. application Ser. Nos. [Not Yet Assigned] (attorney 
1 0 docket 235/1 25), entitled "ADDRESS MAPPING", [Not Yet Assigned] (attorney docket 
235/126), entitled "REMOTE MONITORING AND CONTROL", [Not Yet Assigned] 
(attorney docket 235/127), entitled "GEOGRAPHIC DATA COLLECTION", [Not Yet 
Assigned] (attorney docket 235/128), entitled "COMMAND AND CONTROL 
TRANSFER", and [Not Yet Assigned] (attorney docket 236/259), entitled "BITMAP 
15 TRANSFER", all filed on the same day herewith, and all of which are incorporated herein 
by reference in their entirety. 
Field of the Invention 

The present invention pertains generally to the field of home entertainment 
systems, and more specifically to communication and control technologies in home 
20 entertainment systems. 
Background 

In the past, a home entertainment system frequently consisted of simply a 
television set (TV) and a video cassette recorder (VCR). One or two coaxial or composite 
cables interconnected the TV and VCR from input-to-output and/or output-to-input 
25 respectively. However, in recent years, home entertainment systems have become 
increasingly complex. 

Advances in home electronic devices, such as the compact disk (CD) player, 
digital-video disc (DVD) player, gaming systems, surround sound audio systems, hand 
held video cameras, etc., naturally compelled consumers to connect the additional devices 
30 to their home entertainment system. Each new device added at least two more wires 
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(generally, power and input/output) to the complex web of wires snaking their way in and 
out of the various devices. 

Originally, switch boxes were employed to cut down on the complexity of the 
interconnections between the various devices. For example, a simple "A/B" switch box 
5 allowed a user to selectively choose one input or another, without having to disconnect 
and re-engage coaxial cables between the devices. As the number of devices in home 
entertainment systems increased, however, the use of A/B switch boxes to interconnect the 
devices becomes cumbersome and inefficient. 

Notably, consumers generally desire less wires, simpler interconnect schemes and, 

10 as the functionality and sophistication of home entertainment devices increase, to dispose 
of the myriad individual component remote controls needed to operate the respective 
devices. Indeed, most remote control "features" are never used (see, e.g., "The 
Complexity Problem: Industrial Design", Atlantic Monthly, Vol. 271, No. 3, March 1993, 
p. 96); if for no other reason, this is due to the differing sequences and/or number of steps 

15 involved with the control and operation of each respective device. 

One solution to the aforementioned control problem is proposed in U.S. Patent 
5,675,390 (the "'390 patent") by Schindler et al. As depicted in FIG. 1 of the '390 patent, 
an entertainment system is centrally controlled by a personal computer. According to the 
Schindler et al. system, control is consolidated in the personal computer, wherein a "hub 

20 and spoke", or "star" type communication topology is employed — i.e., with all 

communications passing through the personal computer (or hub). By this configuration, 
each device requires its own dedicated connection to the personal computer. Such a 
solution may work well for tightly integrated home electronics equipment and a 
sophisticated computer user. However, it requires an even greater number of 

25 interconnecting wires than were previously employed. (Note the number of I/O plugs 
depicted in FIG. 7 of the '390 patent). Further, such a system is not scalable. That is, as 
new devices are to be added to the system, additional corresponding adapters/controllers 
must be added to the personal computer. 

A similar solution is proposed in U.S. Patent 5,722,041 (the '"041 patent") by 

30 Freadman. FIG. 2 of the '041 patent best depicts Freadman's home entertainment system. 
Like Schindler et al., control is centrally located in a personal computer. Media feeds are 
through a combination multi-channel modem and analog radio frequency mixer, which 
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connects to a number of terminal devices through a coaxial cable. Although a reduction in 
the number of wires is accomplished, shared functionality between the devices is minimal, 
e.g., one device doesn't control another device and vice-versa. 

In particular, adding a user-operated personal computer to control a home 
5 entertainment system network does not, in itself, reduce complexity. In fact, it may 
increase the complexity. The computer is often difficult, if not cumbersome to control. 
Hardware and software components generally need to be configured to communicate, and 
the devices properly initialized. Upgrades to either peripheral devices (e.g., VCRs, TVs, 
etc.) or the computer itself may necessitate a complete overhaul of the system operating 
1 0 software, thereby introducing incompatibilities and uncertainties in the system 
performance. 

With regard to the myriad interconnection wires in more complex home 
entertainment systems, one solution is the IEEE 1394-1995 standard and its extensions 
IEEE 1394a, and IEEE 1394b, which are referred to herein as "IEEE 1394". In one 

1 5 embodiment, a IEEE 1394 cable is a six strand cable: one strand for power, one strand for 
ground, two strands for data, and two strands for strobes used to synchronize the data 
strands. In an alternative embodiment, a four strand cable can be used, omitting the power 
and ground strands. IEEE 1394 cable also comprises a shield, which prevents 
electromagnetic interference. At its core, IEEE 1394 cable is essentially a high 

20 performance serial bus, having data rates as of this present writing of up to 400 megabits 
per second. 

Advantageously, the IEEE 1 394 bus reduces the need for the myriad wires in a 
home entertainment system, as the component electronic devices may be designed to 
receive power and communication through the IEEE 1394 cable, thereby reducing the 

25 connections needed for most devices to as few as a single cable in a backplane bus 

environment. The IEEE 1394-1995 standard provides a specification for aspects of the 
physical, link and transaction layers for implementing of the IEEE 1394 bus, including 
provisions for such functions as resetting the bus, bus arbitration, node configuration, 
standard packet structures, initializing packet transmission, sending and receiving 

30 asynchronous packets, sending and receiving isochronous packets, transaction control, and 
error detection and correction. 
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Communication over IEEE 1394 bus differs from many previous technologies in 
that it is purely digital. In particular, data carried on the IEEE 1394 bus is either digital 
from the source (e.g., a CD-ROM), or it must be converted by an analog-to-digital 
converter before being placed on the IEEE 1394 bus. Further, communication in a IEEE 
1394-based system is peer-to-peer, i.e., each device (ak.a. "node") on the IEEE 1394 bus 
can communicate with any other node without requiring communication/control requests 
to be processed through a central device/node (e.g., as is required in a "client-server" type 
configuration). In a IEEE 1394-based system, the controller can reside in any node, so in 
a sense, the IEEE 1 394 bus itself becomes the controller. 

Challenges for proponents of IEEE 1394 have been not been so much at the lower 
layers of operation, that is in the physical, link and transaction layers (although bridges 
between protocols and data packet structure continue to be areas of contention), but rather 
in the high layers of the network protocol stack, such as the application layer. Recent 
developments in the broadcast television and cable industries, such as high definition 
television (HDTV) and consolidation in the cable broadcast industry are exponentially 
expanding the number of services and content available to consumers. To this end, 
interoperability between home electronic devices is strongly desired, as are common 
and/or standard functionality, ease of use and scalability. As such, there is a need for a 
system to control and manage the expanding array of devices and services that can be 
connected and supported, respectively, in a IEEE 1394-based home entertainment system. 

SUMMARY OF THE INVENTION 

In accordance with a first aspect of the present invention, a method is provided for 
formatting and routing data between an external network and an internal network, wherein 
the method includes: 

receiving a data packet at a gateway device; 

separating data information from the data packet; 

reformatting the separated data information from a first digital format into a second 
digital format; 

selecting a transmission mode for communicating the data information in the 
second digital format to a particular node residing on the internal network; 
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preparing a portion of the data information in the second digital , format for 
transmission in the selected transmission mode; and 

transmitting the portion of the data information in the second digital format to the 
particular node via the selected transmission mode. 
5 As will be apparent to those skilled in the art, other and further aspects and 

advantages of the present invention will appear hereinafter. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Preferred embodiments of the present invention are illustrated by way of example, 
1 0 and not by way of limitation, in the figures of the accompanying drawings, in which like 
reference numerals refer to like components, and in which: 

FIG. 1 depicts an exemplary IEEE 1394 module architecture; 
FIG. 2 depicts a exemplary IEEE 1394 network topology; 
FIG. 3 depicts an exemplary cable-based IEEE 1394 topology; 
1 5 FIG. 4 depicts an exemplary IEEE 1 394 node protocol stack; 

FIG. 5 depicts a home gateway bridging multiple external service providers with a 
IEEE 1 394-based network; 

FIG. 6 is a functional block diagram of the home gateway of FIG. 5; 
FIG. 7 is an alternate block diagram of the home gateway, illustrating hardware 
20 components; 

FIG. 8 is block diagram illustrating a firmware stack for the home gateway; 
FIG. 9 depicts a protocol stack for MPEG transport over the IEEE 1 394-based 
home entertainment system network of FIG. 5; 

FIG. 10 depicts a protocol stack for IP routing over the home entertainment system 
25 network of FIG. 5; 

FIG. 1 1 depicts a protocol stack for IP plug-and-play and DNS/DHCP routing over 
the home entertainment system network of FIG. 5; 

FIG. 12 depicts a protocol stack for bitmap display data transfer between devices 
of the home entertainment system of FIG. 5; 
30 FIG. 13 is a flowchart depicting a preferred bitmap transfer protocol; 

FIG. 14 depicts a preferred color lookup table structure employed in the bitmap 
transfer protocol; 
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FIG. 15 depicts a preferred image data structure; 
FIG. 16 depicts an address mapping table; 

FIG 17 is a flowchart depicting a preferred command and control transfer protocol; 
FIG. 18 depicts flowcharts pertaining to a data packet engine; 
FIG. 19A-B depict a node navigation tree according to an embodiment of the 
present invention; 

FIG. 19C depicts a node function list according to an embodiment of the present 
invention; 

FIG. 20 depicts a preferred node icon table; 
FIG. 21 depicts a node function table; 

FIG. 22 is a flowchart depicting the acts for generating and maintaining an address 
mapping table; 

FIG. 23 is a flowchart depicting a method for formatting and routing data between 
an external network and an internal network; 

FIG. 24 is a flowchart depicting an MPEG transport stream processing service; 

FIGS. 25A-C are flowcharts depicting various functions and processes of the IP 
service aspect of an embodiment of the present invention; 

FIG. 26 is a flowchart depicting acts for performing remote monitoring and 
control; 

FIG. 27 is a block diagram of a home gateway comprising a positioning unit and a 
central server; 

FIG. 28 is a flowchart depicting a method for collecting statistical geographic 
location information in a network environment as performed by a home gateway; 

FIG. 29 is a flowchart depicting a method for collecting statistical geographic 
location information as performed by a central server; 

FIG. 30 is a diagram of an exemplary statistical data table; 

FIG. 3 1 is a block diagram of a preferred hardware architecture for double- 
buffering; and 

FIG. 32 is a flowchart depicting a method for double-buffering of bitmap transfer 

data. 
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DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

The IEEE 1394-1995 standard, which is hereby fully incorporated herein by 
reference for all that it describes and teaches, provides background information for the 
following description and figures in the accompanying drawings. In particular, selected 
5 portions of the IEEE 1394-1995 standard are described with reference to FIGS. 1 through 
4. 

IEEE 1394 OVERVIEW 
FIG. 1 depicts an exemplary IEEE 1394 module 100, which comprises a plurality 
of addressable nodes 104. Each node 104 may comprise a processor unit 108 and an I/O 
10 unit 1 12 interconnected via a local bus 128. Alternatively, a node 104 may comprise a 
memory unit 116. Each node 104 connects to a IEEE 1394 carrier 120 via a respective 
bus connector 124. 

FIG. 2 depicts exemplary IEEE 1 394 physical network topology 200, which 
comprises two IEEE 1394 "backplane environments" 216 respectively bridged to a IEEE 
15 1394 "cable environment" 212. 

In a backplane environment 216, the physical topology is a multidrop bus 215. The 
physical media includes two, single ended conductors that run the length of the backplane 
and have connectors distributed thereon for connecting a plurality of IEEE 1394 nodes 
104. 

20 In a cable environment 212, the physical topology is a "noncyclic" network 

(meaning that closed loops are not supported) with finite branches and extent. Respective 
IEEE 1394 cables 220 connect together ports 208 on different nodes 104. Each port 208 
typically comprises terminators, transceivers, and arbitration logic circuitry (not shown). 
The cables 220 and ports 208 function, in part, as cable repeaters, which repeat signals 

25 incident thereon to an adjacent node 104. This repeating feature allows nodes 104 in the 
cable environment 212 to simulate a single, logical bus. When two differing IEEE 1394 
buses are connected together, e.g., in a backplane environment 2 1 6 or in a cable 
environment 212, a bridge 204 is used to convert communications between the different 
network environments. 

30 In accordance with the IEEE 1394 standard, a sixty-four bit addressing scheme is 

employed by the IEEE 1 394 network 200. The upper sixteen bits of each address 
represent the "node_ID" The most significant ten bits of the node_ID identify the 
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particular logical bus or "busJD" (e.g., bus 215) in the overall IEEE 1394 network 200. 
Thus, up to one thousand twenty three buses can be employed in the IEEE 1394 network 
200. The, next most significant six bits of the node_ID represent a particular node's 
physical address or "physical_ID'\ Sixty-three independently addressable nodes (e.g., 
5 nodes 104) can reside on a particular IEEE 1394 bus (e.g., bus 215). Various portions of 
the remaining forty-eight bits of address space are allocated for specific resources, either 
to a particular bus, or a particular node. 

FIG. 3 depicts an exemplary IEEE 1394 cable topology 300. In accordance with 
this configuration, a number of nodes 104 are "daisy-chained" together between ports 208 
10 by respective IEEE 1394 cables 304. Each node 104 acts as a repeater, repeating signals 
between one port 208 to the next port so they can be transmitted over the cables 304 
between the respective nodes 104. 

FIG. 4 depicts a protocol stack 400 illustrating the relationships between the 
hardware and software components within an exemplary IEEE 1394 node 104. In 
1 5 particular, four layers are depicted in the protocol stack 400: transaction layer 404, link 
layer 408, physical layer 412, and serial bus management layer 416. Additional layers 
(not shown), such as an application layer, may also be included in the protocol stack 400. 

In particular, the transaction layer 404 defines a complete request-response 
protocol to perform bus transactions to support read, write and lock operations. The 
20 transaction layer 404 also provides a path for isochronous management data to get to the 
serial bus management layer 416. 

The link layer 408 provides for one-way data transfer with confirmation of request 
(i.e., an "acknowledged datagram") service to the transaction layer 404. More 
particularly, the link layer 408 provides addressing, data checking and data framing for 
25 packet transmission and reception, and also provides an isochronous data transfer service 
directly to the application. This includes generation of timing and synchronization signals 
(e.g., a "cycle signal"). 

The physical layer 412 translates logical symbols used by link layer 408 into 
electrical signals for output onto a IEEE 1394 cable. The physical layer 412 also provides 
30 an arbitration service to ensure that only one node at a time is sending data. In a preferred 
embodiment, the physical layer 412 provides data resynch and repeat service, as well as 
automatic bus initialization. 
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The serial bus management layer 416 provides bus management, isochronous 
resource management and node control. For example, in the cable environment 212 of 
FIG. 2, the serial bus management layer's 416 isochronous resource manager 420 grants 
the resources necessary for the respective nodes 104 to allocate and deallocate 
5 cooperatively the isochronous resources, channels and bandwidth necessary for efficient 
and orderly isochronous operations. 

A bus manager 424 provides services, such as performance optimization, power 
and speed management and topology management to other nodes, 104 on the bus. Finally, 
a node controller 428 manages all control and status registers needed by the nodes 104 on 
1 0 the bus, and communicates with the physical layer 412, the link layer 408, the transaction 
layer 404 and one or more other application layers (not shown). 

HOME ENTERTAINMENT AND HOME OFFICE SYSTEM 
FIG. 5 depicts a home gateway 504 bridging multiple external service providers to 
a preferred home entertainment and home office system network, referred hereafter as 
1 5 "home entertainment system network" 500. The home entertainment system network 500 
is connected by an IEEE 1394 bus 568, which is preferably configured in a cable 
environment (described above with reference to FIGS. 2-3). In particular, a series of 
daisy-chained, IEEE 1394 cables 502 interconnect between ports of various electronics 
components of the home entertainment system 500 to form the IEEE 1394 bus 568. For 
20 example, a TV 508, a stereo 5 12, a VCR 5 1 6 and a DVD 520 are connected in one chain 
560. In another chain 564, a personal computer 524, a printer 528, and a digital camera 
534 are connected. 

Each of the respective chains 560 and 564 of electronic components are connected 
to the home gateway 504, which acts as a bridge between one or more external networks 

25 and the respective internal network chains 560 and 564. (i.e., as opposed to a bridge 

between two different bus environments). For example, the home gateway 504 is capable 
of receiving media feeds from a satellite 582 via a satellite receiver 540, a broadcast tower 
586 via an antenna 544, as well as feeds from local land lines 592 (e.g. copper twisted 
pair, coaxial or fiber optic cable) via a coaxial cable receiver 548, fiber optic cable 

30 receiver 552, or telephone cable receiver 556, respectively. (Note: although the various 
receivers are shown outside of the home gateway 504, the actual receivers or receptacles 



WO 00/11840 



PCT/US99/18511 



10 

can be contained within the home gateway 504 as well. They are shown outside of the 
home gateway 504 for illustration purposes only.) 

The TV 508 preferably includes an internal television adapter that converts data 
from the IEEE 1394 bus 502 to NTSC (National Television Standards Committee) and/or 
5 ATSC (Advanced Television Systems Committee) video signals for presentation on the 
television screen. In an alternative preferred embodiment, the television adapter is an 
external device, which connects between the TV 508 and the IEEE 1394 cable 502. In 
either embodiment, the television adapter preferably includes an off-screen buffer, for 
image data not presently displayed, but to be displayed in the future, and an on-screen 
10 buffer, for image data presently displayed on the television screen. Furthermore, the 

television adapter can be incorporated into an auxiliary device connected to the television, 
such as a VCR, a DVD player, or a digital camera. 

HOME GATEWAY 

FIG. 6 depicts a functional block diagram for the home gateway 504, as well as for 

15 the components communicatively coupled to the home gateway 504. 

The gateway 504 comprises one or more interfaces to communicate over an access 
network 644 through which respective services are provided. For example, services from 
an internet access provider ("IAP") or internet service provider ("ISP") 640, or from a 
video service provider ("VSP") 648 can be provided by connecting the respective home 

20 gateway interface, e.g., wireless interface "Terrestrial Broadcast I/F" 650, "Satellite I/F" 
652, asynchronous digital subscriber line interface "ADSL I/F" 656, asynchronous transfer 
mode interface "ATM I/F" 660, or hybrid fiber coaxial interface "HFC I/F" 664, to the 
access network 644 via an appropriate network link, (e.g., terrestrial link 618, satellite link 
620, telephone link 624, fiber link 628, or coaxial link 632, respectively). According to 

25 one preferred embodiment, adapter slots on the home gateway 504 receive one or more of 
the above interfaces. Such an embodiment provides for a flexible reconfiguration when 
new or upgraded communications technologies/hardware are connected to the home 
entertainment system 500. 

A variety of applications are possible over the access network 644 from either the 

30 IAP/ISP 640 and/or the VSP 648, such as internet surfing, MPEG video streams (standard 
and high definition television), network gaming, an electronic program guide "EPG", and 
home network control. Accordingly, the home gateway 504 includes hardware and 
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software to enable home-user IP routing 668, MPEG2 stream handling (including on- 
screen display "OSD" and EPG processing) 672, access network communication control 
676, home network control/management 680, and other resident or downloadable 
functions 682 such as gaming, home automation and directory services. To this end, the 
5 firmware stack for the home gateway 504 is described below with reference to FIG. 8. 
The protocol stacks for implementing the above referenced functions are described below 
with reference to FIGS. 9 through 12. 

The 1394 interface 684 is a necessary component of the home gateway 504 and it 
is used in conjunction with the network protocols described with reference to FIGS. 9-12. 

1 0 The 1 394 interface 684 acts as a bridge between the external network protocols and the 
IEEE 1394 compliant bus which forms the internal network. For example, the 1394 I/F 
684 supports an IP over 1394 link 612 and an MPEG over 1394 link 616, between a 
personal computer 524 and a TV adapter 604 (which, in one embodiment, converts IEEE 
1394 data into an analog or a digital signal for a television 608). 

15 As illustrated in FIG. 7, one embodiment of the home gateway 504 includes a 

power supply circuit 748, a reset circuit 752, a clock circuit 756, a central processing unit 
"CPU" 704, a local bus 706, a PCI bridge & peripheral controller 708, non-volatile 
memory (e.g., ROM 712 and FLASH 71 6), volatile memory (e.g., DRAM 720), an RS232 
interconnect, and a PCI bus 724. Connected to the PCI bus 724 are an ATM LSI interface 

20 728, which provides an ATM bridge and other functionality to the home gateway 504, a 
synchronous optical network ("SONET*) interface 732, which connects to an optical 
carrier 3 ("OC-3") level port, a 1394 LINK LSI 736, a 1394 PHY LSI, with three IEEE 
1394 ports, and a register, LED and dip-switch unit 744. 

Off-the-shelf hardware components are preferrably employed in the home gateway 

25 504. For example, a presently preferred hardware component specification is set forth in 
Table 1 . Where a particular manufacturer's product is preferred, it is specified. 
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Table 1 

CPU 
DRAM 
ROM 
FLASH 
PCI Bridge & 

Peripheral Controller 
1394 LINK LSI 
1394 PHY LSI 
ATM LSI 
Internal Bus 



NR4650 133MHz (NKK Micro Devices) 

8MB 

128 kB 

4MB 

NR4650-PSC (NKK Micro Devices) 

MD841 1 (Fuji Film Micro Device) 
MD8401 (Fuji Film Micro Device) 
LASAR-155 (PMC-Sierra) 
PCI 



The CPU 704, ROM 712, FLASH 716, RS232 724 and DRAM 720 are 
communicatively coupled to each other via PCI bridge & peripheral controller 708 and 

1 5 local bus 706. The PCI bridge & peripheral controller 708 is also connected to the PCI 
bus 724. The PCI bus 724 is, in turn, connected to the ATM LSI 728, the 1394 LINK LSI 
736 and register, LED and dip-switch unit 744. 

FIG. 8 depicts a firmware stack 800, employed by the home gateway 504. An 
operating system (OS) kernel 804 resides at the core of the firmware stack 800, and 

20 communicates with a service controller 808, system management 812, ATM driver 816 
and 1394 driver 820. The ATM driver 816 communicates with the service controller 808, 
the 1394 driver 820 and various hardware components 824 (i.e., physical electronics 
components in the home entertainment system 500.). Similarly, the 1394 driver 820 
communicates with the service controller 808, ATM driver 816 and hardware 824. 

25 System management 812 includes functions for initialization, self-diagnostics, 

system health checking and debugging. Service controller 808 includes functions for 
MPEG TS and EPG filtering and multicasting, IP routing and terminal functions, MPEG 
over the 1394 bus and MPEG over ATM, as well as IP over 1394 bus and IP over ATM, 
address mapping, home network service command and control (e.g., MPEG service 

30 control, TV image control, remote handling, and camera control), and other functions 
(e.g., gaming, home automation, and directory services) 
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The 1394 driver 820 realizes asynchronous data transmission, isochronous data 
transmission, physical layer control packet transmission, bus reset and control, root and 
cycle master processing, configuration status register and configuration ROM handling, 
bus management and address mapping table updates, whereas the ATM driver 816 realizes 
5 ATM pack transmission and ATM permanent virtual connection ("PVC") establishment 
and release. 

The OS kernel 804 provides for task switching, message queue and delivery, 
interrupt handling, timer management and memory management. Also, the OS kernel 804 
provides the electronic device interoperability functions which are used to control home 
10 gateway 504. 

The hardware 824 represents the physical layer, or lowest layer, of the firmware 
stack 800. 

In a presently preferred embodiment, the home gateway 504 functions as a 
bridge/router between the external network 904 and the internal network 912 (described in 

15 detail with reference to FIGS. 9-12 below). The home gateway 504 therefore provides a 
middle-layer between the external network 904 and the internal network 912 that is used 
for protocol and data formatting transformation, as well as address mapping functionality 
(described below). In particular, the home gateway 504 is a preferred "managing node" 
for maintaining the address mapping table (described below with reference to FIG. 16), 

20 wherein the home gateway 504 stores node address information in a memory, periodically 
updates the node address information, polls IEEE 1394 nodes (as used herein, "IEEE 1394 
nodes" refers to.one or more nodes residing on the IEEE 1394 bus 568 and comporting 
with the node 104 described with reference to FIGS. 1-4 above) on the internal network 
912 and gathers node attributes from the polled IEEE 1394 nodes for the address mapping 

25 table 1600. Further details of the address mapping 1600 and the address mapping service 
are described below with reference to FIGS. 16 and 22. 

BRIDGE/ROUTER FUNCTIONALITY 
FIG. 23 depicts a flowchart depicting the acts for formatting and routing data 
between an external network and an internal network. More particularly, FIG. 23 depicts 

30 the acts executed by the home gateway 504 in furthering its bridge/router functionality. It 
should be noted that the functionality depicted in FIG. 23 is described in further detail 
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with regard to the MPEG and IP service sections below. It is the overall bridge/router 
functionality of the home gateway 504 that is the object of the following description. 

The data formatting and routing process begins at act 2304, where a data packet is 
received by the home gateway 504. The information in the data packet is separated at act 
5 2308. For example, header and/or address data is identified, as well as the data packet 
body. In act 23 12, the data packet is transformed from a first digital format, to a second 
digital format. By way of example, act 23 12 may include removing and adding header 
data from and to the data packet body, as well as reformatting the data structures 
themselves from an encrypted to a non-encrypted format. 

10 At act 23 1 6 a test is performed to determine whether the data packet contains real 

time or non-real time data. For example, a command is likely non-real time data. 
However, an MPEG transport stream is real time data. By analyzing the data packet 
header, the home gateway 504 can determine the type of data contained in the data packet. 
If the data packet body contains non-real time data, then processing continues to act 2320, 

1 5 where the data packet body is prepared for transmission as an asynchronous packet on the 
IEEE 1394 bus. On the other hand, if the data packet body comprises real time data, then 
processing continues to act 2324, where the data packet body is prepared for transmission 
over an isochronous channel of the IEEE 1394 bus. Acts 2320 and 2324 both continue to 
act 2328. 

20 In act 2328, the address mapping table 1 600 (described below with reference to 

FIG. 16) is read and address information from the address mapping table is cross- 
referenced. For example, the address information, e.g., the node id or node unique id, of 
the target IEEE 1394 node for the data packet is copied. With the data from act 2328, the 
home gateway 504 appends the address information to either the isochronous (act 2320) or 

25 asynchronous (act 2324) data packet in act 2332. In act 2336, the isochronous or 

asynchronous data packet is transmitted over the selected IEEE 1394 channel or address to 
the target IEEE 1394 node. 

PROTOCOL STACKS 
FIGS. 9 through 12 depict various aspects of the protocol stacks employed between 
30 the respective external networks, the home gateway and the internal network(s), which 
pertain to the home entertainment system network. FIGS. 9-1 1 pertain to the home 
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gateway 504. FIG. 12 pertains to the protocol stack between home electronic devices 
located on the home entertainment system network. 

Commonly shown in FIGS. 9-12 is an external network 904, a bridge 908, and an 
internal network (i.e., IEEE 1 394 bus) 912. The external network 904 can comprise an 
5 MPEG network 916 (e.g., a digital video service provider), and an IP network 920 (e.g., 
the "Internet"). An access network 924 connects to both the MPEG network 91 6 and IP 
network 920. According to one embodiment, the access network 924 is an internet access 
provider ("IAP") such as, e.g., America Online or @Home. The external network 904 is 
coupled to the internal network 912 through a bridge 908. The bridge 908 is preferably an 

1 0 home gateway 504. The home gateway 504 converts data and signals from the external 
network 924 from ATM packets to an IEEE 1394 format, which can be forwarded to the 
internal network 912. The internal network 912 comprises a television adapter 932 and a 
standard or high definition television 936 (or alternatively a single unit incorporating a 
1 394 node and a television) and a personal computer 946. The protocol stacks are 

1 5 depicted in FIGS. 9-12 under the portion of the overall system to which they correspond. 

FIG. 9 depicts the protocol stack 900 according to ATM data transmission from an 
MPEG network 916 to a TV adapter 932. 

MPEG data is formatted at the MPEG network 916 from MPEG TS ( 4t transport 
stream") protocol or control command ("CTRL COM") 956 to ATM adaption layer 5 

20 ("AAL5") 952. From AAL5, the data is converted to ATM data 948, and from ATM 948 
it is converted to synchronous optical network "SONET" protocol 944. An ATM network 
is preferred at the lowest layer, given its high reliability, but in alternative embodiments, a 
different carrier can be employed (e.g., by replacing the ATM layers). 

From the access network 924, data is received at the home gateway 504. At the 

25 home gateway 504, the communications from the external network are converted (or 
"bridged") from an ATM protocol to an IEEE 1394 protocol. Additional protocol layer 
conversions are shown in FIG. 9, including IEC 61883 964, which formats MPEG data for 
IEEE 1394 communication and is further described in International Electrotechnical 
Commission Standard 61 883 entitled "Digital Interface for Consumer Audio/Visual 

30 Equipment" and which is publicly available from the IEC (www.iec.org). IEEE 1394 
protocol 968, is described in the IEEE 1394-1995 standard. 
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From the gateway 908, data is sent via IEEE 1394 protocol to the internal network 
912, where it is subsequently converted back into an MPEG transport stream for 
presentation/playback on a video display unit. It is further possible with TV adapter 932 
to convert the data to an analog signal cable of providing audio/visual data to a standard or 
5 high definition television set. Preferably, however, TV 936 is capable of supporting 
MPEG data. 

FIG. 10 depicts a protocol stack 1000 according to IP data transmission from IP 
network 920 to PC 946. The transmission control protocol ("TCP") or user datagram 
protocol ("UDP") 1008, which are described in publicly available documents Internet RFC 

10 793 and Internet RFC 768 respectively, are layered over internet protocol ("IP") 1004, 
which is described in Internet RFC 791. This facilitates transmission of packet data from 
an internet (e.g., the Internet or World-Wide Web). At the home gateway 504 and PC 946, 
an IP over 1394 protocol 1012, described in Internet Engineering Task Force ("IETF") 
document "IPv4 over IEEE 1394", by Peter Johansson and available at 

15 <http://www.ietf.org>, is employed. The IETF document "Ipv4 over IEEE 1394" is 
incorporated herein by reference in its entirety. The protocol stack 1000 is especially 
advantageous for finding or exploring content on the World-Wide Web and Internet. 

FIG. 1 1 illustrates a protocol stack 1 100 for TCP/IP data transmission from the IP 
network 920 to the PC 946. In order to facilitate automatic setup and IP address 

20 assignments, the protocol stack 1 100 supports a domain name system ("DNS"), as 
described in Internet RFCs 1034 and 1035, and dynamic host configuration protocol 
("DHCP"). 

FIG. 12 illustrates a protocol stack 1200 for bitmap transfer between devices (e.g., 
from the home gateway 504 or PC 946 to the TV adapter 932) over the internal network 
25 912. The protocol stack 1200 employs additional and previously non-described protocol 
"DD-Connect AsyBmp" 1204. The "bitmap transfer" protocol is described in further 
detail below. The "AP" protocol 1208 is simply the particular protocol used at the 
application layer (e.g., a display protocol or a mouse protocol). 

MPEG SERVICE 

30 According to a presently preferred embodiment, the home gateway 504 manages 

incoming MPEG transport stream service from a video service provider on the MPEG 
network 916 to an IEEE 1394 node in the IEEE 1394 internal network 912. The MPEG 
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service is handled by ATM driver 816, service controller 808 and IEEE 1394 driver 820 
within the home gateway 504. FIG. 24 is a flowchart depicting the acts for processing 
MPEG data between the external network 904 and the internal network 912. 

Turning to FIG. 24, at act 2404, an asynchronous write request is received at the 
5 IEEE 1 394 driver 820 from an IEEE 1394 node. The asynchronous write request 
comprises an MPEG START REQUEST command. The MPEG START REQUEST 
command is passed from the IEEE 1394 driver 820 to the service controller 808, at which 
point isochronous resource allocation begins. In act 2408, an asynchronous write request 
comprising an MPEG START RESPONSE is sent from the service controller 808 to the 
10 IEEE 1394 driver 820, and then from the IEEE 1394 driver 820 to the target IEEE 1394 
node. 

Next, in act 2412, an asynchronous write request comprising an MPEG READY 
command is received at the IEEE 1394 driver 820. The MPEG READY command is 
passed from the IEEE 1394 driver 820 to the service controller 808. MPEG data is 

1 5 received at the ATM driver 8 1 6 at act 24 1 6. Although act 24 1 6 is shown after act 24 1 2, it 
is possible that the MPEG data was received before act 2412. The MPEG data is received 
over an AAL5 connection with the video service provider on the MPEG network 916. 

At act 2420, the service controller requests the 1294 driver 820 to enable 
isochronous transmission over the pre-allocated isochronous channel by sending an MPEG 

20 TALK START request. In act 2424, the service controller 808 sends a VC ENABLE 

request to the ATM driver 816 to request an isochronous virtual channel ("VC"). Next, in 
act 2428, an asynchronous write request comprising an MPEG READY response is sent 
from the service controller 808 to the 1394 driver 820, from which it is then sent to the 
target IEEE 1394 node. 

25 In act 2432, an MPEG data is received at the ATM driver 8 1 6. In act 2436 an 

MPEG DATA SEND request is passed from the ATM driver 816 to the IEEE 1394 driver 
820. Next, in act 2440, the MPEG DATA SEND requestis followed by MPEG data. 
MPEG data is then routed to the target IEEE 1394 node. At act 2444, the service 
controller 808 performs a test to determine whether an asynchronous write request 

30 comprising an MPEG STOP command has been received from the target IEEE 1 394 node. 
If the test at act 2444 is negative, then processing continues to act 2432 described above. 
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If the test at act 2444 is positive, meaning an MPEG STOP command was received, then 
processing continues to act 2448. 

At act 2448, the service controller 808 passes a request to the ATM driver 816 
requesting to disable (or close) the isochronous virtual channel. At act 2452, the service 
5 controller 808 sends a MPEG TALK STOP response to the IEEE 1 394 driver. Finally, at 
act 2460, the isochronous resources are released, wherein an MPEG STOP response is sent 
from the service controller 808, through the IEEE 1394 driver 820 and then to the IEEE 
1394 node. 

IP SERVICE 

10 In a presently preferred embodiment, the home gateway 504 further manages IP 

service to and from IEEE 1394 nodes on the IEEE 1394 internal network 912 and the 
external network 904. For the purpose of illustration, the external network 904 is 
described as communicating via an asynchronous transfer mode ("ATM") protocol, since 
it is preferred. However, alternative embodiments of the invention allow for 

1 5 communication via non-ATM protocols too, such as IP through an internet access provider 
or internet service provider (e.g., transmission control protocol "TCP"), a cable modem, 
asynchronous digital subscriber line, or other equivalent communication protocol. 

FIGS. 25A-C are flowcharts depicting the acts for IP service support. More 
particularly, FIG. 25A depicts general IP packet support for IP routing or forwarding, FIG. 

20 25B depicts ARP (address resolution protocol) support, and FIG. 25C depicts IP packet 
"ping" support. The IP support services described herein are event (or interrupt) driven 
support algorithms and begin upon receipt of a trigger, for example the receipt of an IP 
packet at the ATM driver 816. Publicly available Internet Architecture Board documents 
RFC 791, 826 and 2151 describe, respectively, further information concerning the IP 

25 packet handling, ARP and ping request handling. These documents, which are 

incorporated herein by reference in their entirety, are, as of the date of this writing, freely 
available from <http://sunsite.cnlab-switch.ch/>. Accordingly, the information provided 
hereafter concerning the IP service of the home gateway 504 is designed to be a general 
overview of its manner of operation. 

30 FIG. 25A is a flowchart depicting the acts for handling IP packets for routing or 

forwarding. At act 2504, an IP packet received at the ATM driver 816 is tested to 
determine whether it contains an IP packet indication. If the packet does not contain an IP 
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packet indication, then the routine will stop until a next IP packet is received. However, if 
the packet does contain an IP packet indication, then processing continues to act 2508, 
wherein the ATM driver 816 forwards the IP packet indication to the service controller 
808. The service controller 808 reads the address mapping table 1600 (described in detail 
5 with reference to FIG. 16) and matches the destination IP address contained in the IP 
packet with a corresponding IEEE 1394 node. 

The home gateway 504 formats the IP packet for routing to the destination IEEE 
1394 node. To this end, in act 2512, an asynchronous WRITE REQUEST is initialized 
with an IP packet and passed from the service controller 808 to the IEEE 1394 driver 820, 
1 0 and then from the IEEE 1 394 driver 820 to the destination IEEE 1 394 node. Since the 
aforementioned process is event driven, the present iteration is finished after act 2512, so 
the process returns to a "waiting" mode, where the IP service routine waits for a next IP 
packet. 

FIG. 25B depicts acts for processing an address resolution protocol ("ARP") 

15 request. ARP is a protocol for finding a physical address (e.g., Ethernet address) from an 
Internet address. Generally, a requester broadcasts an ARP packet comprising the Internet 
address of another host and then waits for the other host to send back its representative 
physical address. The home gateway 504 maintains the address mapping table 1600, 
which is used, in part, to this end. When an ARP request is received at the home gateway 

20 504, the home gateway 504 can return a physical address by querying the address mapping 
table 1600 and finding a physical address corresponding to the received IP address. This 
ARP request response is possible even though the IP address is not necessarily the home 
gateway 504 IP address. Indeed, the IP address is more likely to be the IP address of 
personal computer (e.g., personal computer 524) residing on the IEEE 1394 bus 568. 

25 Turning to the acts depicted in FIG. 25B, in act 2524, the packet is tested to 

determine whether it comprises an ARP request. If the packet does not contain an ARP 
request, then the process returns to act 2524. Notably, act 2524 is performed based on an 
event trigger - receiving a packet; it is not a constant polling. If the packet does contain 
an ARP request, then processing continues to act 2528. 

30 In act 2528, the ARP request is passed from the ATM driver 8 1 6 to the service 

controller 808. The service controller reads the address mapping table 1600 to determine 
whether the IEEE 1394 node identified by the Internet address in the ARP resides on the 
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IEEE 1394 bus 568. If the IEEE 1394 node identified by the Internet address does not 
reside on the IEEE 1394 bus 568, the present iteration of the process ends. However, if 
the IEEE 1394 node does reside on the IEEE 1394 bus 568, then the physical address of 
the IEEE 1394 node is retrieved from the address mapping table 1600 in act 2532. 

In act 2536, the physical address is populated into an ARP response, and in act 
2540, the ARP response is forwarded from the service controller 808 to the ATM driver 
816, and then from the ATM driver 816 to the external network 904. The present iteration 
of the process ends after step 2540, so the processing will begin (i.e., on its next iteration) 
at act 2524. 

FIG. 25C depicts steps for processing a "ping". A ping is an echo request that is 
used to determine whether a particular device is "on-line" or "live". The "ping" process is 
known in the art, nevertheless, a high-level overview is described herein for illustration 
purposes. 

In act 2544, the IP packet is tested to determine whether it contains a "ping" 
request directed to the home gateway 504. If the IP packet does not contain a ping request 
for the home gateway 504, then the iteration ends and the process returns to act 2544 
(similar to acts 2504 and 2524 above). However, if the IP packet does contain a ping 
request for the home gateway 504, then processing continues to act 2548. 

In act 2548, the ping request is passed from the ATM driver 8 1 6 to the service 
controller 808, where the IP address contained in the ping request is tested against the 
home gateway 504 IP address. If the two IP addresses match, then processing continues to 
act 2560, described below. If the two IP addresses do not match, then processing 
continues to act 2552. 

In act 2552, the service controller 808 reads the IP addresses contained in the 
address mapping table 1 600. In act 2556, a test is performed to determine whether there is 
a match between the incoming IP address contained in the ping request and any IP address 
in the address mapping table 1600. If there is no match as a result of the test at act 2556, 
then the iteration terminates and processing returns to act 2544 (note that no response to 
the ping is given in this instance). 

If, however, a match between the two IP addresses does exist, then processing 
continues to act 2558, where the ping request is forwarded to a particular node on the 1394 
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bus. The particular node will respond appropriately to the ping request. Accordingly, the 
process returns to act 2544. 

In act 2560, a response to the ping request is generated by the service controller 
808, passed to the ATM driver 816 and then forwarded to the external network 904. 
5 Processing of the ping request terminates and a next iteration can be processed once a new 
ping request is received. 

BITMAP TRANSFER 
To reduce demand on system resources, for example, IEEE 1394 cable bandwidth, 
an asynchronous push protocol, called "bitmap transfer", is preferably employed to send 
1 0 image data from one device (i.e., a personal computer 946 or home gateway 504) to a 
second device (i.e., a television) within the internal network 912. The bitmap transfer is 
layered over the IEEE 1394 asynchronous mode functionality. 

More particularly, on-screen display ("OSD") information is first placed into a 
bitmap format, for example, representing color data (e.g., red, green, blue) levels for each 
15 image pixel (or area) on the display monitor. In one embodiment, twelve-bit color pixel 
data is employed, however, in an alternative embodiment, twenty-four-bit color pixel data 
is employed, the latter giving a higher color resolution, but giving up processing speed and 
data storage space. 

A preferred series of steps for the bitmap transfer (also called "DD-AsyBmp") are 
20 depicted in FIG. 13 and described below with reference to FIGS. 14-15. For purposes of 
illustration, the description below will be described with reference to a controller, e.g., 
home gateway 504 depicted in FIG. 6, and a video display unit, e.g., TV adapter 604, also 
depicted in FIG. 6. In other embodiments, the controller can be implemented in a personal 
computer (e.g., personal computer 524 depicted in FIG. 5). In the acts of the method that 
25 follows, the acts are performed by the controller, unless otherwise stated. 

First, in act 1304, a first image data is received at the controller. The first image 
data is preferably a fixed-format data structure, such as a bitmap image. The bitmap 
image comprises a plurality of locations, with each location having a unique color 
assigned to it (e.g., twelve-bit or twenty-four-bit color information in a Y, Q,,C r , format 
30 that includes an additional four or eight bits for an a value too, such as, 6:3:3:4 (YUV 
alpha) bits and 8:8:8:8 (YUV apha) bits). The first image data is stored in memory at act 
1308. 
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Next, in act 1312, the controller generates a color lookup table (described below 
with reference to FIG. 14) based on the unique colors detected in the first image. Notably, 
the color lookup table is independent of pixel location information and is concerned only 
with the color data contained in the image data. According to one embodiment, generation 
5 of the color lookup table comprises the acts of extracting a plurality of unique colors from 
the first image data, assigning a unique key value to each of the plurality of unique colors 
extracted from the first image data, and then populating the color lookup. table with the 
unique key values and corresponding color information. 

The color lookup table is transmitted to the video display unit at act 1316. Next, in 
10 act 1320, the first image data is transmitted to the video display unit. The structure of the 
image data is described below with reference to FIG. 15. 

In act 1324, a new image data is received by the controller. An image counter is 
incremented in act 1328. In act 1 332 the image counter is tested to determine whether to 
simply forward the new image or to compare and generate image change information. In a 
1 5 presently preferred embodiment, a new color lookup table is generated after every Nth 
image received. The value of N can be tuned to correspond to a certain time period 
(milliseconds). Accordingly, if the image counter is greater than N, then the controller 
processing returns to act 1312 after act 1332. Depending on the image counter used, the 
image counter should be reset if the test at act 1332 is successful. If the image counter is 
20 less than or equal to N, then processing continues to act 1336. 

In act 1 336, the new image data and the prior stored image data are compared. If 
the images, or the present regions-of-interests are the same, then a change does not need to 
be sent from the controller to the video display unit. Accordingly, the controller can return 
to act 1324 and wait for a next new image data. If, however, the images are not the same, 
25 then the colors of the new image data are compared with the colors in the color lookup 
table in act 1340. 

If, as a result of the comparison in act 1340, the colors are not the same, then a new 
color lookup table is generated in act 1344 and transmitted to the video display unit in act 
1348. However, if the colors are the same, then processing continues from act 1340 to act 
30 1352. 

In act 1352 an image body data is generated to reflect the changes between the 
stored image data and the new image data received. At act 1356, the image body data 
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together with the image body data data dictionary is transmitted from the controller to the 
video display unit. At act 1360, the new image data received (i.e., by the controller in act 
1324) is stored in memory and processing returns to act 1324 - where a next new image 
data is received. 

5 In a presently preferred embodiment, the bitmap transfer method described above 

is performed over an IEEE 1394 bus in an asynchronous push mode. Accordingly, it is 
preferred that an acknowledge signal is returned from the video display unit to the 
controller after each transmission to ensure that the data was properly received at its 
destination. 

10 COLOR LOOKUP TABLE 

An exemplary color lookup table is depicted in FIG. 14. The lookup color table 
1400 comprises at least two structural elements. First, the lookup color table 1400 
comprises a unique key value column 1404. Second, it comprises a color indicator value 
column 1408. According to a presently preferred embodiment, the unique key value 

1 5 column 1404 holds eight-bit entries, which uniquely identify two-hundred fifty-six colors, 
or, in other words two-hundred fifty-six color indicator rows 1440. The color indicator 
value column 1408 holds sixteen-bit entries (twelve-bits of color information 1444 and 
four-bits of reserved space 1448) which uniquely identify a particular color code needed to 
create an RGB or similarly encoded color image on the video display unit. In alternative 

20 embodiment, the color indicator column 1408 holds thirty-two-bit entries (twenty-four bits 
of color information and eight-bits of reserved space). Similarly, the unique key value 
column 1404 can be larger to represent a greater number of distinct colors in the color 
lookup table. 

In a presently preferred embodiment, the color lookup table 1400 further comprises 
25 a data dictionary 1412, which is information about the data that follows, i.e., here, the 

color indicator fields. The data dictionary 1412 comprises a data structure identifier field 
1416, for example a one-byte value indicating the present data structure is a color lookup 
table, a palette fragment number field 1420, identifying the fragment of the overall image 
to which the color table applies, a number of fragments value field 1424, identifying the 
30 number of fragments in the overall image, and a palette bit width value field 1428, 

identifying the number of bits in each color indicator column. Finally, two bytes (bytes 
1432 and 1436) are reserved in the presently preferred data dictionary 1412. 
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The data dictionary 1412 is approximately six bytes long and the color indicator 
fields (all together) are approximately five hundred twelve bytes long. The data dictionary 
1412 generally immediately precedes the color indicator rows 1440. 

IMAGE DATA STRUCTURE 
5 The structure of the image data transmitted by the controller to the video display 

unit is depicted in FIG. 15. The image data structure 1500 comprises two parts, a image 
data data dictionary 1 504 and an image data body 1 508. 

The image data data dictionary 1504 preferably comprises an image data identifier 
field 1512, telling the receiver that the data structure is image data, a pixel block size field 

10 1516, indicating the structure of the image data body (for example, the number of pixels 
represented in the image data body 1508), a color mode field 1520 (e.g., eight-bit pixel 
index, sixteen-bit color information, or thirty-two-bit color information), a pixel block 
alpha field 1524, and coordinates for the pixel position, for example, sixteen-bit x, y 
encoded values indicating the top-left position 1528, the top-right position 1532, the 

15 bottom-left position 1536 and the bottom-right position 1540. Alternatively, the 

coordinates for the pixel position can be a single value indicating a particular pre-defined 
region-of-interest. Two reserved bytes are also contained in data dictionary 1504, they are 
shown as reserved byte 1544 and 1548. Except as otherwise specified above, the preferred 
field size for the image data data dictionary 1504 is eight-bits. 

20 The image data body 1508 can presently have three different embodiments. The 

pixel block size field 1516 and the color mode field 1520 define which of the three 
embodiments the image data body will take. For example, the image data body 1508 can 
comprise an eight-bit pixel index, sixteen-bit color information, or thirty-two-bit color 
information. The sixteen- and thirty-two-bit color information formats are substantially 

25 the same as the color indicator column 1408 described with reference to FIG. 14, except 
that the color information is contained in the image body data 1508. However, according 
to one of the advantages of the present inventions, the color information is compressed by 
employing the eight-bit pixel index as the structure for the image body data 1 508. 

According to the eight-bit pixel index embodiment, only seven hundred sixty-eight 

30 (e.g., 32 x 24 pixels) bytes (e.g., byte 1552) of image body data 1508 are needed to convey 
the image data completely to the video display unit. Redundancies in color information 
are accordingly removed from the image body data 1508 by use of the combination of the 
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color lookup table 1400 and the eight-bit pixel index. The eight-bit pixel index comprises 
a plurality of color lookup values wherein each color lookup value represents a particular 
pixel in the present image. The color lookup values correspond to a particular unique key 
value 1452 in the color lookup table 1400. Accordingly, when the image data body 1508 
5 size is fixed, for example to 768 bytes, then the eight-bit pixel index embodiment can 
communicate twice as much image pixel information as the 16-bit color information 
embodiment and four times as much image pixel information as the 32-bit color 
information embodiment. 

DOUBLE BUFFERING 

10 FIG. 31 depicts a block diagraip of presently preferred hardware 3 100 for 

performing a unique bitmap transfer technique referred to herein as "double-buffering". 
FIG. 32 is a flowchart depicting the steps performed on the receiving side of a bitmap 
transfer protocol when double-buffering is employed. 

Turning first to FIG. 3 1, a central server 3 104 sends data, such as MPEG streams, 

1 5 from a video or internet service provider to a home entertainment network system 500. 

A video display adapter 3108 can be any of a number of home electronic devices, 
such as a home gateway 504, a VCR, a DVD player, etc. Shown here, the video display 
adapter 3 1 08 comprises a first interface 3 1 24, preferably an ATM interface, a controller 
3128, preferably an IEEE 1394 compliant node, coupled to the first interface 3124, and a 

20 second interface 3132, preferably an IEEE 1394 bus interface, coupled to the controller 
3 1 28. The video display adapter 3 1 08 components are coupled via a local bus 3 156. 
Furthermore, the controller 3 128 is configured to execute sequences of instructions from a 
computer-readable medium, such as a ROM (not shown). The sequences of instructions 
are described below with reference to FIG. 32. Finally, the video display adapter 3108 is 

25 communicatively coupled to the central server 3 1 04 via ATM communication link 3116. 

A video display unit 31 12 is communicatively coupled to the video display adapter 
3108, preferably via an IEEE 1394 communication link 3120. The video display unit 
3112 comprises two general parts: a television adapter 3 1 48 and a television display 
screen 3152. According to an alternative embodiment, however, the television adapter 

30 3 148 does not have to be part of the single video display unit, that is, in the same physical 
packaging. Rather, the television adapter 3 148 can be a stand-alone unit, or it can be 
embedded into the video display adapter 3 1 08, such as a home gateway 504. 
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The television adapter 3 148 preferably comprises an interface 3136, for receiving 
the IEEE 1394 communication link 3120, and two display buffers, namely, on-screen 
display buffer 3140 and off-screen display buffer 3144. The interface 3136, the on-screen 
display buffer 3140, and the off-screen display buffer 3144 are communicatively coupled 
5 via a local bus 3 160. According to one embodiment, control logic is implemented by an 
IEEE 1394 node (not shown) in the television adapter 3148. In an alternative 
embodiment, control logic is implemented by a field programmable gate array "FPGA", or 
transistor-transistor logic "TTL" circuitry. 

The on-screen display buffer 3140 is configured to store image data that is 

1 0 currently presented on the television display screen 3 1 52, whereas the off-screen display 
buffer 3 144 is configured to store image data that will be, in the future, displayed on the 
television display screen 3152. Accordingly, the television display screen 3152 is coupled 
to the on-screen display buffer 3 1 40 via link 3 1 64. However, in an alternative 
embodiment, both the on-screen display buffer 3 140 and the off-screen display buffer 

15 3 1 44 are coupled to the television display screen 3 1 52 and image data presented on the 
television display screen 3 1 52 can be presented from either buffer. 

With regard to the description of the method for double-buffering that follows, it is 
notable that reserved byte 1 544, depicted in FIG. 15, is used herein as a buffer control 
register. The buffer control register holds one of a number of flags communicating 

20 information concerning double-buffering. For example, one flag is an on-screen display 
buffer flag, another is an off-screen display buffer flag, and a third flag is a swap flag. . 
These flags are described in greater detail herein. 

FIG. 32 depicts a method for double-buffering of bitmap transfer data according to 
a preferred embodiment of the present invention. In act 3204, a color lookup table 1400 is 

25 received by the television adapter 3 148 and stored in a memory (not shown). Next, in act 
3208, image data 1500 is received by the television adapter 3148. In acts 3212 through 
3220, a image data data dictionary 1504 is analyzed to determine the value of the buffer 
control register. 

If the value of the buffer control register 1544 indicates that the image data 
30 contained in the image data body 1508 should be placed into the on-screen display buffer, 
then processing continues to act 3224, where the image data in the image data body 1508 
is stored in the on-screen display buffer 3140. Subsequently, the image data in the on- 
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screen display buffer 1508 is presented on the television display screen 3152. Under 
normal circumstances, presenting the image data on the television display screen 3152 
includes retrieving color values from the color lookup table 1400 that was received in act 
3204. In certain circumstances, a color lookup table 1400 is not received for every single 
5 image data 1 500 received by the television adapter 3 148, rather, the color lookup table 
1400 is shared between successive image data 1500. 

If the value of the buffer control register 1 544 indicates that the image data 
contained in the image data body 1508 should be placed into an off-screen display buffer 
3144, then processing continues to act 3232, where the image data in the image data body 
1 0 1 508 is stored into the off-screen display buffer 3 144. 

If the value of the buffer control register 1 544 indicates a "swap", then no image 
data body 1508 is received by the television adapter 3148. Rather, the image data in the 
off-screen display buffer 3 1 44 is copied to the on-screen display buffer 3 140 in act 3236. 
Subsequently, processing continues to act 3228, which was previously described. 
15 After acts 3232 and 3228, as well as after an invalid flag from the buffer control 

register, the present iteration of the method ends, and processing can continue again at act 
3204, or alternatively act 3208. 

Successive receipts of image data for the on-screen display buffer 3140 and the 
off-screen display buffer 3 144, followed by a "swap" flag, can create the perception of 
20 animation on the television display screen 3 1 52. The present technique is useful for 

displaying animated movement of objects for advertising, as well as scrolling banners or 
text. Notably, since the buffer control register 1544 is controlled by the controller 3128, 
the timing of the animation effects are too. 

ADDRESS MAPPING 

25 FIG. 16 depicts an exemplary address mapping table 1600. The address mapping 

table 1 600 preferably comprises at least four columns and as many rows as there are 
devices on the home entertainment network 500. The address mapping table 1600 is 
preferably partitioned into three distinct sections. The first section 1620 comprises IEEE 
1394 service data, the second section 1624 comprises MPEG service data, and a third 

30 section 1628 comprises IP service data. Each section has its own "mini-table" for 
information, although the address mapping table 1600 is physically a single table. 
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In the IEEE 1394 section 1620, the first column is the node unique ID column 
1604, the node unique ID is permanently encoded into the hardware or ROM of the node 
104. The next group of columns are node attribute columns 1602. The node attribute 
columns include a common name column 1608, which identifies a particular node by a 
5 user selected/programmed name that is stored in the node, a nodejtt) column 1612, which 
contains a dynamically assigned 16-bit node_ID, a node type column 1616, and an IP 
address column 1618. 

In the MPEG service section 1624, the first column is the ATM VPI/VCI column 
1632, the next column is the program information column 1636, the third column is the 
1 0 IEEE 1 394 isochronous channel column 1 640 and the last column is the node unique ID 
column 1604. 

In the IP service section 1628, the first column is the ATM VPI/VCI column 1632, 
the next column is the IP address column 1618, the third column is the node_ID column 
1612, and the last column is the node unique ID column 1604. 

1 5 The address mapping table 1 600 is created by the IEEE 1 394 driver (e.g., IEEE 

1394 driver 816 shown in FIG. 8) when a bus reset occurs. The IEEE 1394 driver receives 
a response from each node in the IEEE 1394 bus (e.g., IEEE 1394 bus 568 shown in FIG. 
5) identifying the node's node unique ID and other information. Based on the information 
received from the node, the IEEE 1 394 driver adds the node unique ID to the address 

20 mapping table 1 600 and then queries the particular node for additional information (e.g., 
common name, node capabilities and IP address). The IEEE 1394 driver assigns a valve 
to node_ID column 1612 for the node. 

FIG. 22 is a flowchart depicting the acts for generating and maintaining the address 
mapping table 1 600. The acts are performed by a "managing node" residing on the home 

25 entertainment network system 500 and, more preferably, the acts are performed by the 
home gateway 504. The node managing the address mapping table 1600 is generally pre- 
selected. However, it can be dynamically changed either in response to a bus reset, or by 
express instruction from a user. In either event, the functionality for generating and 
maintaining the address mapping table 1600 is embedded into the IEEE 1394 driver 820. 

30 At the outset of the address mapping process, a trigger is received which causes the 

address mapping table 1600 to be generated. The trigger is either an internal or external 
trigger, relative to the managing node, such as a bus reset command. The bus reset can 
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occur as a result of an explicit instruction from the application layer, or by an implicit 
instruction from the firmware - such as in response to the IEEE 1394 driver 820 detecting 
a new node added to the home entertainment network system 500. The trigger is shown as 
a bus reset in FIG. 22, act 2200. 
5 After receiving a trigger, the processing continues to act 2204, where a self- 

identification packet is receiving by the managing node. The self-identification packet 
comprises sixteen-bit address information referred to above as a "node_ID". The 
node JD, more particularly the ten-bit bus JD and the six-bit physicalJD, is extracted 
from the self-identification packet at act 2208. 

10 In act 22 12, a new row is added to the address mapping table 1 600. The data 

extracted at act 2208 is filled into the bus_ID and physical_ID fields in act 2216. In a 
preferred embodiment, the two fields are a single sixteen-bit address space — i.e., the 
node_ID column 1612. 

In act 2220, the managing node prepares and transmits an asynchronous read 

1 5 request addressed to the node identified by the node_ID received at act 2204. In response 
to the asynchronous read request, the managing node receives an asynchronous read 
response at act 2224. The asynchronous read response comprises at least a node unique 
, identifier ("ID") and preferably also comprises additional node attribute information, such 
as an IP address, a node type, and a common name. 

20 In act 2228, the node unique ID and, according to a presently preferred 

embodiment, the additional node attribute information, are extracted from the 
asynchronous read response received at act 2224. In act 2232, the node unique ID is filled 
into the node unique ID column of the address mapping table 1600. In a preferred 
embodiment, the additional node attribute information is also filled into a corresponding 

25 column of the address mapping table 1 600. In the event that a partitioned address 
mapping table 1600 is used, the rows of the address mapping table 1600 are logically 
separated corresponding to the type of service the data in the row pertains to, for example, 
IEEE 1394 service, ATM service, or MPEG service. In such an embodiment, the node 
attribute information identifies which partition the node information corresponds to. In 

30 another embodiment, redundant data is stored in mini service tables within the primary 
address mapping table 1600. 
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Finally, in act 2236, a test is performed to determine whether any new node self-ID 
packets have been received by the managing node. If any new node self-ID packets have 
been received, then processing continues to step 2208. If no new node self-ID packets 
have been received, then processing ends. 
5 In the broader spirit of the invention, the steps described above can be handled in a 

batch mode, wherein after a bus reset (i.e., act 2200), a collection period elapses during 
which node self-ID packets are received and queued into a list in memory by the managing 
node. In such an embodiment, the processing of node self-IDs and the attainment of node 
unique IDs and node attribute information can be handled from the queued list in an 

1 0 incremental fashion. The test, therefore, in act 2236 becomes whether any additional self- 
ID packets need to be processed. 

When a command directed toward a particular node in the home entertainment 
network system 500 is received, the command is related to the particular bus_ID and a 
physical_ID (or node_ID) using the address mapping table 1 600. The managing node then 

1 5 uses the particular bus_ID and physical ID to address (or direct) the received command to 
a particular node in the home entertainment network system 500. 

COMMAND AND CONTROL TRANSFER 
FIGS. 17-20, depict aspects of command and control transfer according to a 
presently preferred embodiment of the present invention. Moreover, FIGS. 17 and 18 are 

20 flowcharts illustrating the steps for command and control transfer and packet data 
handling, respectively, whereas FIGS. 19A-C depict an embodiment of the display 
information that is created on a video display unit as a result of the steps depicted in FIGS. 
17 and 18. FIG. 20 illustrates a node icon table. 

To begin the command and control transfer process, a trigger is received. For 

25 example, a trigger can include a "menu" button on a remote control that initiates the 
command and control transfer process, or a stored procedure in a device residing in the 
home entertainment network 500. As shown in FIG. 17, a packet engine output from 
process 1804 (described below with reference to FIG. 18) can initiate the acts for 
command and control transfer. 

30 Act 1704 includes reading the address mapping table 1600. Once the address 

mapping table 1600 is read, a node icon table is read in act 1708. 
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The node icon table has no less than two columns and identifies an image for each 
device on the home entertainment network 500. The first column represents a node (for 
example, either a node unique ID or a node type), and the second column represents the 
node's icon. It is, however, possible to have additional columns in the table, such as a 
5 node type, and a node unique ID. Accordingly, if a particular node's icon is desired, the 
first the node icon table is scanned for the node's unique ID, if the node unique ID is not 
found, then the node icon table is scanned for the desired node type (e.g., the node can be 
compliant with a particular device standard). When a matching node unique ID or, 
alternatively, a matching node type is found, then the icon for the desired node is retrieved 
10 at act 1716. 

An embodiment of a node icon table is depicted in FIG. 20. The node icon table 
2000 includes node unique ID column 1604, a node type column 1608, and a bitmap data 
column 2004. The bitmap data column holds approximately 4kB of data for the node icon. 
In one embodiment, data for a single icon is contained in the node icon tabie 2000, 
15 however, in an alternative embodiment, data for two icons is contained in the node icon 
table 2000: one icon is an "inactive" icon, meaning the icon displayed when the node is 
not selected, and the second is an active node icon, meaning the icon displayed when the 
node is selected. 

In act 1720, a complete node navigation tree is generated. The node navigation 
20 tree is depicted in FIGS. 19A-B. In FIG. 19A, the node navigation tree 1900 comprises a 
control node represented by icon 1904. The control node is the node through which a user 
is communicating. Destination nodes are represented by icons 1908, 1912 and 1916. As 
depicted in FIG. 19A, control node's icon 1904 is in active mode, whereas the destination 
nodes' icons 1908, 1912 and 1916 are in inactive mode. When additional nodes are added 
25 to the home entertainment system 500, the number of destination node icons will increase. 
Similarly, when existing nodes are removed from the home entertainment system 500, the 
number of destination node icons will be reduced accordingly. 

The node navigation tree 1900 is transmitted to the video display unit at act 1724. 
According to one embodiment, the node navigation tree 1900 is output to a packet engine 
30 1 800, where it is processed as an input to process 1 808 (described below with reference to 
FIG. 18). 
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In act 1728 a navigation input is received. Again, the navigation input can be 
received from an input device within the internal network 912 (FIG. 9), or it can be 
received from the external network 904, such as through the packet engine process 1804. 
Based on the input received in act 1728, a particular destination node will be identified. 
5 The control node retrieves the icon information (e.g., the active mode graphic) from the 
node navigation table 1600, and, in act 1732, modifies a subset of the navigation tree 
1900. In an alternative embodiment, standard active mode data, such as a highlighted 
border or ring, is added to the portion of the navigation tree 1900 representing the selected 
destination node, thus, retrieval of active mode icon data from the address mapping table 

1 0 1 600 is not required. Based upon the active mode data, a portion, or subset of the node 
navigation tree 1900 is modified. The portion of the node navigation tree 1900 modified 
can include modified data corresponding to the "newly" selected active node, or it can 
additionally include modified data corresponding to the node which has been switched 
from active mode to inactive mode. According to a presently preferred embodiment, both 

15 data concerning the new active node icon and the old active node icon are modified. 

FIG. 19B depicts the node navigation tree 1900 after the destination node 
corresponding to icon 1916 has been selected as the active node. The portion of the node 
navigation tree 1900 that has been modified is the subset of data corresponding to icons 
1904 and 1916. In act 1736 the modified subset of the node navigation tree 1900 is 

20 transmitted to the video display unit. In an alternative embodiment, the modified subset of 
the node navigation tree 1900 is passed to the packet engine 1 800 and routed to the 
external network 904 by process 1808. 

An optional intermediate act can occur between acts 1736 and 1740. The optional 
step is confirming from the user that the destination node that was navigated to in act 1728 

25 is in fact the desired destination node. This act is simply receiving another input, such as 
an "ENTER" command after navigation to the desired destination icon. 

In act 1740 the node function table is read. FIG. 21 depicts a node function table 
21 00. The node function table 21 00 preferably comprises two columns, a node type 
column 1616 and a function list column 2104. The function list column 2104 comprises a 

30 plurality of entries, each entry 2108 comprising a mapping of single character 

alphanumeric inputs, a corresponding function name and an op code. When the controller 
reads the node function table 2100, the node function table 2100 is scanned for the 
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particular active destination node type and the corresponding entries 2108 containing the 
valid commands for the active destination node. The valid commands are retrieved in act 
1740. 

In act 1 744 a node function list, based on the data retrieved from act 1 740 is 
5 generated. The node function list is then transmitted to the video display unit in act 1748. 
Again, transmission to the video display unit can also include sending the outgoing node 
function list to the packet engine for processing and routing by process 1808. 

FIG. 19C depicts a node function list 1928 as presented on the video display unit. 
The first column of the node function list 1928 represents an input value column 1920. 
10 The second column, text column 1924, represents text corresponding the adjacent input 
value, the text describing the function that will result if the adjacent input value in column 
1 920 is received by the controller. 

In act 1752 a node function input is received at the controller. The input can come 
over the IEEE 1394 bus 568, or it can come from an external network 904, in which case 
15 the node function input is directed to the controller by packet engine 1800. The node 
function input is compared against valid input values 1920 in act 1756, and if the node 
function input matches a valid input value 1920; then the controller continues to act 1764. 
If, however, the node function input does not match a valid input value 1920, then the 
controller continues to act 1760, where an error message (e.g., "invalid command, please 
20 re-enter") is transmitted to the video display unit (or packet engine 1 800). From act 1760, 
processing continues to act 1752. Alternatively, processing can continue to step 1748, 
such that the video display unit can be refreshed. 

Finally, the input value 1 920 received at the controller is mapped to a function in 
the node function list 1928. A command is formatted with an appropriate op code and is 
25 transmitted to the destination node in act 1764. After act 1764, the command and control 
transfer method is complete. 

PACKET ENGINE 

FIG. 18 depicts packet engine 1800. According to one embodiment, packet engine 
1800 is a software bridge/router that receives and formats data for and from the internal 
30 network 912 and the external network 904. However, packet engine 1 800 can also be 

implemented in hardware alone, or a combination of hardware and software. The steps for 
passing a data packet from the external network 904 to the internal network 912 are 
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depicted in process 1 804, whereas the steps for passing data from the internal network 912 
to the external network 904 are depicted in process 1808. 

In process 1 804, a data packet is received from the external network 904 at act 
1810. In act 1 8 1 2 the data packet is parsed into an input request - for example a node 
5 function input - and output routing information - for example, information necessary to 
send a response back the data packet sender. In act 1 8 16 the input request is formatted 
and sent to the controller. 

In process 1 808 data output (e.g., the node navigation tree 1 900) is received at the 
packet engine 1800 from the internal network 912 at act 1824. In act 1828 data received 
1 0 from the internal network is formatted into acceptable data packet for routing over the 
external network. The output routing information parsed at step 1812 of process 1804 is 
used to this end. According to one embodiment an acceptable data packet is an IP packet 
in another embodiment an ATM packet is acceptable. 

REMOTE MONITORING AND CONTROL 
15 In the home entertainment system network 500 comprising the hopie gateway 504, 

it is possible to monitor and control nodes on the internal network 912 from the external 
network 904. In such an embodiment, the address mapping table 1600 facilitates 
communication between a device residing on the external network 904 and the node on the 
internal network 912. 

20 The home gateway 504 (described above) preferably maintains the address 

mapping table 1 600 and acts as a "gatekeeper" for inbound and outbound data from/to the 
external network 904. Furthermore, the home gateway 504 functions as a repository for 
information pertaining to the home entertainment system network 500, storing in memory 
(e.g., flash memory 716 or DRAM memory 720) node attribute information such as node 

25 type, compatibility, and additional ATM, MPEG, IEEE 1394 and IP service information. 
Service controller 808 handles much of the functionality described below. 

In one embodiment, the home gateway 504 includes in the firmware stack 800 a 
SNMP (simple network management protocol) manager and agent. The SNMP agent 
responds to queries concerning the IEEE 1 394 nodes in the home entertainment network 

30 system 500 and effectively provides the home gateway 504 the ability to respond to 

queries from other SNMP managers. The information queried by the SNMP managers is 
contained in a management information base ("MIB"), which is stored in the home 
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gateway 504. One embodiment of a MIB is the address mapping table 1600, together with 
other tables such as the node functionality table 2100. In an alternative embodiment, 
another MIB, such as one defined by RFC 1213 is employed. SNMP is further described 
in Internet Architecture Board document RFC 1 157, which are publicly available, at the 
5 time of this writing, at <http://sunsite.cnlab-switch.ch/>. 

Furthermore, the SNMP agent is capable of initiating tasks requested by particular 
IEEE 1394 nodes in the system 500. For example, the SNMP manager may receive a 
request for a bus reset. The request for the bus reset is passed to the SNMP agent, and the 
SNMP agent then causes the 1394 driver 820 to trigger the bus reset. Another example is 

1 0 receiving a command passed through a remote SNMP manager. The command, like the 
request described above, is passed to the SNMP agent and the SNMP agent processes the 
command and formats it for transmission to the subsequent layer - e.g., the 1394 driver 
820, or the OS kernel 804. 

In another embodiment, the home gateway 504 incorporates web-server 

1 5 functionality. More specifically, the home gateway 504 serves requests from outside 

clients, for example a web browser, and returns information about IEEE 1394 nodes in the 
home entertainment network system 500. For example, in one embodiment requests for 
the node navigation tree 1900 and responses returning the node navigation tree 1900 are 
handled by the web-server. Thus, the web-server includes functionality, such as that of the 

20 packet engine 1 800 described above with reference to FIG. 1 8. The web-server 

functionality is substantially similar to the SNMP functionality but with the web-server, 
the monitoring and control is preferably controlled through a remote client such as a web 
browser. Commands from the outside client can also include a bus reset, a trigger to cause 
a VCR to start recording, or a switch to lock a door or turn out a light. 

25 In either the web-server or SNMP manager embodiments, a central office or 

monitoring site, for example the VSP 648 or IAP/ISP 640 (described above with reference 
to FIG. 6), is capable of monitoring devices within the home entertainment network 
system 500. 

The remote monitoring and control acts are depicted in FIG. 26. The acts are 
30 performed by the home gateway 504, and can be performed more particularly by the 
SNMP manager and agent, or the web-server component of the home gateway 504. 
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In act 2604, an output data packet is received at the home gateway 504. In act 
2608, the output data packet is parsed. For example, a input data packet is separated from 
other header or meta data, which describes the remote client and information about the 
input data packet (e.g., security information, remote IP address, etc.) The input data 
5 packet is transmitted from the home gateway 504 to the target node in act 2612. 

In act 2616, a response to the input data packet transmitted in act 2612 is received 
at the home gateway 504. An output data packet is generated in act 2620, and in act 2624, 
the output data packet is returned to the remote client that requested the information. 

The address mapping table 1600 is highly useful in the remote monitoring and 
10 control aspects of the invention. For example, the address mapping table 1600 is used for 
act 2612 to assist in addressing the target IEEE 1394 node in the home entertainment 
network system 500 for which the request or command is directed. Similarly, the address 
mapping table 1600 can also be used to authenticate requests for data or commands from 
the remote client by including the IP address, or other address information (e.g., node 
1 5 unique ID) to verify authority of the remote client to request such data or commands. 

Furthermore, the IP service description (described above with reference to FIGS. 25A-C) 
is also useful in understanding the more general description of remote monitoring and 
control set forth above. 

GEOGRAPHIC DATA COLLECTION 

20 FIG. 27 depicts a block diagram of a hardware architecture of an IEEE 1394 home 

gateway node 2700 configured to collect geographic statistical data, together with a central 
server 2750 (e.g., a central office server or a head-end server). In a preferred embodiment, 
the home gateway 2700 is similar to home gateway 504, with only selected components of 
the home gateway 2700 shown for simplicity. The home gateway 2700 comprises a 

25 central processing unit 704, a persistent memory, such as non- volatile memory 2712, an 
external network interface 2704, such as ATM LSI 728 (not shown in FIG. 27 — shown in 
FIG. 7), an internal network interface 2708, such as 1394 LINK LSI 736 (not shown in 
FIG. 27 — shown in FIG, 7), and a positioning unit 2716. The non-volatile memory 2712 
is communicatively coupled to the CPU 704 via a local bus 706, whereas the CPU 704, 

30 external network interface 2704 the internal network interface 2708 and the positioning 
unit 2716 are communicatively interconnected via PCI bus 724. 
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Central server 2750 is preferably an enterprise quality server, such as a Sun™ 
Enterprise™ 250 system, available from Sun Microsystems in Mountain View, California 
<http://www.sun.com> running a client-server software system, such as an Oracle 8™ 
database, available from Oracle Corporation in Redwood Shores, California 
5 <http://www.oracle.com>. Central server 2750 is operated by a service provider, such as a 
cable or video service provider and is located at a remote location relative to the home 
gateway 2700. 

Central server 2750 is depicted in block diagram format as having a CPU 2754, a 
non- volatile memory 2758 (e.g., a persistent disk), and an external network interface 2762. 

1 0 The CPU 2754, the NV memory 2758 and the external network interface 2762 are 
communicatively coupled via a local bus 2756. The central server 2750 and the home 
gateway 2700 are communicatively coupled via a physical medium between the external 
network interfaces 2704 and 2762, such as fiber optic cable 2702. Other coupling 
mediums can include copper (twisted pair or coaxial) and wireless interfaces. 

15 The positioning unit 2716, shown in home gateway 2700, can have multiple 

embodiments. For example, in one preferred embodiment, the positioning unit 2716 
comprises a global positioning module such as the ACE II GPS™ module that is available 
from Trimble Navigation in Sunnyvale, California <http://www.trimble.com>. However, 
a particular, or highly accurate global positioning module is not necessarily required, as 

20 the geographic resolution of the unit is not critical. By way of further example, 

geographic location data is to be requested by the central server 2750 - e.g., from a cable 
provider - thereby triggering the global positioning module to update location information 
for the home gateway 2700. The positioning unit 2716 then provides the updated location 
information to the central server 2750 - for example, directly from the positioning unit 

25 2716 or via the CPU 704. 

In an alternative, and more cost effective embodiment, a persistent memory, such 
as a non-volatile RAM, can be employed in the positioning unit 2716, together with a 
software based user prompt that is initialized during the home gateway 2700 power-up, or 
at a user's request. The user prompt directs a user to manually enter a geographic location 

30 identifier, such as a zip code, and the user response is recorded into the non-volatile RAM. 
When subsequent request for geographic location information for the home entertainment 
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network system 500 are made, the home gateway 2700 can respond by returning the 
location identifier stored in the persistent memory. 

FIG. 28 is a flowchart depicting a method for collecting statistical geographic 
location information in a network environment, such as the home entertainment network 
5 system 500. The method is preferably performed via a sequence of instructions - e.g., a 
firmware routine - executing in the home gateway 2700. 

Referring to the first act depicted in FIG. 28, a test is performed by the home 
gateway 2700 at act 2804 to determine whether the location information stored in the 
positioning unit 271 6 is current. Under normal circumstances, the test is performed on a 

1 0 regular, e.g., biweekly basis, so a counter/timer may be used to determine whether the 

geographic location information is current. Preferably the counter/timer is set to reflect an 
invalid time whenever a power off occurs, thereby forcing an update of the geographic 
location information. If the counter/timer is current, then the process continues to act 
2816, otherwise, the process continues to act 2808. 

15 In act 2808, the processing unit 2716 retrieves geographic location information 

either automatically (e.g., through a global positioning module), or manually (e.g., through 
a user prompt and response). In act 2812, the geographic location information is stored in 
a persistent memory in the home gateway 2700 - e.g., NV memory 2712, or in a dedicated 
persistent memory (not shown) which is part of the positioning unit 2716. 

20 ; In act 28 1 6, incoming content information from the external network 904, which is 

passing through the external network interface 2704, is sampled. The sampled incoming 
data includes a channel identifier and can also include a broadcaster's time and date stamp. 
In act 2820, the sampled data is recorded in statistical data table 3000 (described in detail 
with reference to FIG. 30) residing in a persistent memory, e.g., NV memory 2712. In a 

25 preferred embodiment, each time a channel is changed on an IEEE 1394 node in the IEEE 
1394 bus 568 for a period longer than a predetermined length of time, e.g., five minutes, 
the home gateway 2700 will create a corresponding record in the statistical data table 
3000. 

In act 2824, a test is performed to determine whether a request has been received 
30 for statistical geographic data. Generally, the statistical data request will come from the 
central server 2750 at a broadcaster's facility over the external network 904. However, the 
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statistical data request can come from within the home entertainment network system 500, 
such as, for example, by a parent wishing to review a child's viewing habits. 

If a statistical data request has not been received, then the present iteration of the 
process ends and the home gateway 2700 cycles back to act 2804. If, however, a 
5 statistical data request has been received by the home gateway 2700, then processing 

continues to act 2828, where the sampled data contained in the statistical data table 3000 is 
encrypted. According to an embodiment, a public key/private key encryption pair is used 
for the decryption/encryption mechanism, such as the Message Digest 5 "MD5" algorithm. 
The MD5 algorithm is described in the publicly available Internet RFC 1321, entitled, 

1 0 "The MD5 Message Digest Algorithm", R.Rivest, 1992, <http://sunsite.cnlab-switch.ch>, 
and which is incorporated herein by reference in its entirety. 

After the information from the statistical data table is encrypted, it is transmitted, 
together with the location identifier (if needed), over the external network interface 2704 
to the central server 2750 at act 2832. Notably, if only particular home gateways 2700 

1 5 having a particular location identifier are polled at any given time, then it may not be 

necessary to include the location identifier. However, if periodic updates are pushed from 
the home gateway 2700 to the central server 2750, then the location identifier becomes 
necessary. Thereafter, the present iteration of the process terminates and a new cycle can 
begin again at act 2804. 

20 FIG. 29 is a flowchart depicting a method for collecting statistical geographic 

information from a network environment by the central server 2750. The method is 
preferably performed via sequences of instructions - e.g., an application - running on the 
central server 2750. Beginning at act 2904, the central server 2750 initializes 
communication with the home gateway 2700. 

25 According to one embodiment, the initialization sequence includes authenticating 

the identity of both the central server 2750 to the home gateway 2700, as well as the home 
gateway 2700 to the central server 2750. In another embodiment, the authentication 
process further includes registering additional IEEE 1394 nodes residing in the home 
entertainment network system 500. This can be performed by including selected data such 

30 as the node unique IDs from the address mapping table 1600 (described in detail with 
reference to FIGS. 16 and 22). 
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In yet another embodiment, when the geographic location information/identifier is 
recorded in the home gateway 2700 at act 2808 (FIG. 28), the location identifier is stored 
in both the address mapping table 1600 and within a reserved persistent memory location 
of each IEEE 1394 node residing on the IEEE 1394 bus 568 (when write access is 
5 allowed). When a bus reset occurs, discrepancies between the location identifiers, e.g., 
between any IEEE 1394 node and the home gateway 2700, detected by the home gateway 
2700 or the central server 2750 triggers the authentication/registration process with the 
central server 2750. Alternatively, the home gateway 2700 can periodically synchronize a 
portion of its address mapping table 1 600 with the central server 2750. The node unique 

10 ID of the particular IEEE 1394 node (which has a differing location identifier) and the 
node unique ID of the home gateway 2700 are then reconciled by the central server 2750. 
If, for some reason, the discrepancy cannot be reconciled, then appropriate service 
personal can be notified of either a potential user error or a stolen device. 

After act 2904, the central server 2750 requests sampled statistical data, e.g., all or 

1 5 only a portion of the statistical data table 3000, from the home gateway 2700 in act 2908. 
After requesting the sampled statistical data, the central server 2750 will wait for a period 
of time for the sampled statistical data in act 2912. If no sampled statistical data is 
received, then processing continues to act 2904. However, if sampled statistical data is 
received, then processing continues to act 2916. 

20 In act 2916, the sampled statistical data received from the home gateway 2700 is 

decrypted. Again, according to one embodiment, the encryption/decryption algorithm is 
the MD5 function described herein with reference to Internet RFC 1321. 

In act 2920, the decrypted sampled statistical data is analyzed for viewing patterns 
and user preferences. Based upon the sampled statistical data, particular content, such as 

25 types of advertising or program listings, can be selectively broadcast to a user viewing 
content passing through the home gateway 2700. For example, if a user consistently 
watches a particular program or channel, then that program or channel may be thereafter 
marked as a "preferred" viewing channel in an electronic program guide. Similarly, 
demographics, e.g., age, sex or zip code of a particular user, or group of users who view a 

30 particular program, can also be recorded. Based upon the demographics of a particular 
program, advertising geared toward the particular user or group of users can be broadcast 
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with the program, as well as enhanced viewing information, such as uniform resource 
locators, "URLs", related to the program and user preferences. 

FIG. 30 is a diagram of an exemplary statistical data table 3000. The statistical 
data table 3000 has five columns, although it could have more or less columns in alternate 
5 embodiments. The node unique ID column 3004 stores a unique identifier for each IEEE 
1394 device receiving content through the home gateway 2700 at a given instant. The 
channel column 3008 stores an identifier for the particular channel that is being piped 
through the home gateway 2700. A timestamp/counter field 3012, e.g., a 16-bit time and 
date stamp, for uniquely identifying a particular date and time for each record, stores the 

1 0 time viewing began for a particular user and channel. Similarly, the timestamp/counter 
field 3016 is used to record the data and time when viewing ended for the particular user 
and channel. The timestamp/counter data for fields 3008 and 3012 is preferably generated 
and broadcast by the central server 2750 so as a standard frame of reference is used when 
analyzing the statistical data. Alternatively, the timestamp/counter can be generated by 

1 5 the home gateway 2700, however it should still be periodically synchronized with the 
central server 2750. User field 3020 records a user identifier for the particular statistic 
data record. For example, users knowing a password to disable parental control can be 
assigned a predetermined user identifier. 

Three rows 3024, 3028, and 3032 are shown in the statistical data table 3000. For 

20 example, when analyzed by the central server 2750, the information stored in rows 3024 
and 3028 communicates that User A watched channel "2" on a Mitsubishi TV for six 
minutes on a particular date and at a particular time. Furthermore, the records indicated 
that User A thereafter switched to channel "4", wherein they continued to watch for nine 
additional minutes. Row 3032 indicates to the central server 2750 that while User A was 

25 viewing channel "4", User B tuned in channel "2" on a different IEEE 1394 node (here on 
an ACME PC) for twenty-six minutes. The information in the statistical data table 3000 
can be augmented with the address mapping table 1600 (described herein) to add depth to 
the data samples. 

The methods and processes described herein are preferably performed by one or 
30 more processors executing one or more sequence of instructions stored on a computer- 
readable medium, such as a persistent disk, a CD-ROM, a floppy disk, a volatile memory 
(e.g., random access memory "RAM"), or a non-volatile memory (such as a flash memory 
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or read-only memory "ROM"), rather than in a particular hardware arrangement. 
However, in the broader spirit of the inventions, various aspects of the methods and 
processes described herein can be implemented via hardware components such as TTL 
logic, or gate arrays. Furthermore, if a preference for a firmware level, e.g., a lower level 
5 programmic implementation of software component that is, generally, stored in ROM, or 
an application level, e.g., a higher level programmic implementation of a software 
component that runs over firmware, an operating system kernel, and/or server processes, 
software component is desired, then that preference is specified. If no preference is 
specified, then either level of implementation is acceptable. Accordingly, the written 
10 description and accompanying figures contained herein are to be regarded in an 
illustrative, rather than a restrictive sense. 
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CLAIMS 

What is claimed is: 

1 . A method for formatting and routing data between an external network and an 
internal network, comprising: 

receiving a data packet at a gateway device; 
separating data information from the data packet; 

reformatting the separated data information from a first digital format into a second 
digital format; 

selecting a transmission mode for communicating the data information in the 
second digital format to a particular node residing on the internal network; 

preparing a portion of the data information in the second digital format for 
transmission in the selected transmission mode; and 

transmitting the portion of the data information in the second digital format to the 
particular node via the selected transmission mode. 

1 5 2. The method of claim 1 , wherein selecting the transmission mode includes: 
determining whether the data information is real time or non-real time data; 
if the data information is real time data, then selecting an IEEE 1394 isochronous 
channel for communicating the data information to the particular node; and 

if the data information is non-real time data, then selecting an IEEE 1394 

20 asynchronous channel for communicating the data information to the particular node. 

3, The method of claim 1 , wherein preparing the portion of the data information for 
transmission comprises: 

reading an address mapping table and retrieving node address information for the 
particular node; and 

25 appending the node address information for the particular node with the portion of 

the data information in the second digital format. 

4. The method of claim 1, wherein the data packet is received at the gateway device 
through an external network interface configured to use an asynchronous transfer mode 
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protocol and wherein the data packet is router to an internal network interface configured 
to use an IEEE 1394 protocol. 

5. A method for remote monitoring and control of devices (nodes) in a network 
system including a gateway device bridging the network system to an external network, 

5 comprising: 

maintaining an address mapping table within the network system, the address 
mapping table comprising a node unique identifier column and node attribute information; 

receiving an input data packet from the external network at the gateway device; 

parsing the input data packet into an output request and input data; 
10 mapping the input data to a particular node on an internal network connected to the 

gateway device; 

transmitting the input data to the particular node; 

receiving a response from the particular node; 

generating an output data packet comprising the response from the particular node; 

15 and 

forwarding the output data packet to the external network. 

6. The method of claim 5, wherein the network system comprises an IEEE 1 394 bus 
and the external network comprises a packet data network. 

7. The method of claim 5, wherein the network system comprises an IEEE 1 394 bus 
20 and the external network comprises an asynchronous transfer mode network. 

8. The method of claim 5, wherein maintaining the address mapping table comprises: 
storing node address information in a memory; 

updating the node address information in response to a node address information 
update trigger; 

25 polling particular nodes in the internal network; and 

gathering particular node attributes from the particular nodes. 
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9. The method of claim 5, further comprising establishing a peer-to-peer two way 
communication channel between a first device connected through the external network and 
a second device connected to the internal network. 

10. The method of claim 5, wherein the address mapping table is stored in the gateway 
5 device. 



1 1 . The method of claim 5, wherein 1 the network system comprises a home 
entertainment system and the gateway device is a home gateway. 

12. A method of transferring image data from a controller to a video display unit, 
comprising: 

1 0 receiving first image data at the controller; 

generating a color lookup table based on the first image data; 
transmitting the color lookup table from the controller to the video display unit; 
transmitting the first image data from the controller to the video display unit; 
receiving second image data at the controller; 
15 comparing the second image data to the first image data; 

generating third image data representing differences between the first image data 

and the second image data; and 
transmitting the third image data from the controller to the video display unit. 

The method of claim 12, wherein the color lookup table is generated by 
extracting color information including one or more unique colors from the first 
image data; 

assigning a unique key value to each unique color extracted from the first image 
data; and 

populating the color lookup table with the unique key values and corresponding 
color information. 



13. 



20 



25 



14. The method of claim 12, wherein the third imaging data is transmitted to the video 
display unit over an IEEE 1394 asynchronous transmission mode. 
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15. The method of claim 12, wherein the third image data represents color differences 
between the first and second image data. 

16. A video display unit adapter, comprising: 

a first interface configured to receive successive image data transmissions; 
5 a controller coupled to the first interface and configured to 

receive a first image data transmission from the first interface and 
generate a corresponding color lookup table, and 

receive a second image data transmission from the first interface 
and generate image update data representing differences between the first 
10 and second image data transmissions; and 

a second interface coupled to the controller and configured to transmit the 

respective color lookup table and image update data to a video display unit. 

17. The video display unit adapter of claim 16, wherein the first interface is an IEEE 
1394 interface. 

15 18. The video display unit adapter of claim 1 6, wherein the second interface is an 
IEEE 1394 interface. 

19. The video display unit adapter of claim 18, wherein the second interface transmits 
the color lookup table and image update data to the video display unit over an IEEE 1394 
asynchronous transmission mode. 

20 20. The video display unit adapter of claim 1 6, wherein the first interface receives data 
in a non IEEE 1394 compliant format, and wherein the second interface transmits data in 
an IEEE 1394 compliant format. 

2 1 . The video display unit adapter of claim 1 6, wherein the image update data 
represents color differences between the first and second image data 
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22. A gateway device, comprising: 
a central processing unit; 

an external network interface communicatively coupled to the central processing 

unit; 

5 an internal network interface communicatively coupled to the central processing 

unit; 

a positioning unit communicatively coupled to the central processing unit, the 
positioning unit configured to record geographic location information; 

a first persistent memory communicatively coupled to the central processing unit; 

10 and 

a data table stored within the first persistent memory, the data table configured to 
store statistical data pertaining to content received through the external network interface 
and geographic data pertaining to nodes communicatively coupled to the internal network 
interface. 

15 23. The gateway device of claim 22, wherein the positioning unit comprises a global 
positioning system transceiver. 

24. The gateway device of claim 22, wherein the positioning unit comprises a second 
persistent memory configured to be manually updated so as to store therein a geographic 
location identifier. 

20 25. A method for transmitting command and control information between at least two 
nodes of a network, comprising: 

dynamically generating a node navigation tree; 
transmitting the node navigation tree to a video display unit; 
receiving a node navigation input identifying a particular node in the node 
25 navigation tree; 

modifying a subset of the node navigation tree based on the node navigation input; 
transmitting the modified subset of the node navigation tree to the video display 
unit; 
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generating a node function list including one or more functions pertaining to the 

identified node; 
transmitting the node function list to the video display unit; 
receiving a node function input corresponding to a particular node function in the 

node function list; and 
transmitting a command to the identified node based on the node function input. 

26. The method of claim 25, wherein the navigation tree is generated from data stored 
in a node address table. 

27. The method of claim 25, wherein the node function list is generated from data 
stored in a node function table. 

28. The method of claim 26, further comprising 

relating each node identified in the node address table to a node type; 

reading a node icon table, the node icon table having a node type column and a 
node icon column, wherein each row of the node icon table identifies a 
particular node type and a graphical icon for the node type; 

retrieving one or more graphical icons from the node icon table; and 
causing one more of the graphical icons to be displayed on the video display unit. 

29. The method of claim 25, further comprising 

receiving input data packets from an external network, the data packets comprising 

an output request and input data; 
parsing the respective output request and input data from the data packets; 
formatting the input data as node navigation input; and 
generating an output data packet comprising a response to the output request. 

30. A method for address mapping in a network system, comprising: 
receiving a self identification packet; 

extracting a bus identifier and a physical identifier from the self identification 

packet; 
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adding a new row to an address mapping table, the new row comprising a bus 
identifier field, a physical identifier field, and a node unique identifier field; 

inserting the physical identifier and the bus identifier into the respective bus 
identifier field and physical identifier field in the new row of the address mapping table; 
S transmitting a read request packet to a node identified by the self identification 

packet; 

receiving a read response packet, the read response packet comprising a node 
unique identifier; 

extracting one or more identifiers from the read response packet, the one or more 
1 0 identifiers including a node unique identifier; and 

inserting the one or more identifiers into additional fields in the new row of the 
address mapping table. 

3 1 . The method of claim 30, the read response packet further comprising node attribute 
information, the method further comprising adding the node attribute information to one or 

1 5 more fields in the new row of the address mapping table. 

32. The method of claim 30, further comprising partitioning a plurality of unique 
records into three or more logically distinct sections, the three or more logically distinct 
sections including: 

an IEEE 1394 bus service section; 
20 an MPEG service section; and 

an IP service section. 

33. The method of claim 30, further comprising: 

receiving a command pertaining to a particular node in the network system; 
relating the command to a particular bus identifier and physical identifier using the 
25 address mapping table; and 

sending the command to the particular node using the particular bus identifier and 
physical identifier. 
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34. The method of claim 30, wherein the transmitting and receiving acts are performed 
via an IEEE 1394 bus. 

35. The method of claim 30, wherein the network system comprises a home 
entertainment system. 
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